I don't really understand the point of this, can you try explaining the advantage?

Also doesn't this destroy the heap property that timers are in? (at least I think they are in a heap)

I don't really understand the point of this, can you try explaining the advantage?

The original code calls timer->add on every execution, unconditionally allocating a new timer slot even when the computed interval is identical (player count hasn't changed). With the persistent interval timer, the common case (no player count change) becomes a no-op. timer->set_interval is only called when the interval actually differs.

Also doesn't this destroy the heap property that timers are in? (at least I think they are in a heap)

No, it doesn't disturb the heap. The heap (timer_heap) is a min-heap ordered by tick (next fire time), see the DIFFTICK_MINTOPCMP comparator in timer.c. timer_set_interval only modifies timer_data[tid].interval, which is never a heap key. The interval field is read only inside do_timer to compute the next tick after a fire event. Changing it mid-life has no effect on the current heap ordering.

but overall, you're correct to question it. there's no meaningful advantage, and the complexity cost outweighs the gain. We should close this.